home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0288.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  4.8 KB  |  95 lines
  1. >> The arguments that in-band designation of document format is better
  2. >> than out-of-band information may apply in the electronic mail
  3. >> scenarios, where there is a single sender, multiple recipients, and
  4. >> the recipient has no control over what the sender might send.
  5.  
  6. >The argument is identical for most file servers, which have even less control
  7. >over the specifics of what files they offer for retrieval. File servers usually
  8. >rely on contributed material and only rarely have anything resembling precise
  9. >control over the material they offer.
  10.  
  11. But we are not discussing 'file servers' in general, but something
  12. more specific and presumably over which we have more control: use of
  13. MIME content identifiers to identify content-type in World-Wide-Web
  14. and WAIS servers. Even in the case of file servers, while you might
  15. not have control over the material offered, you do have control over
  16. the description of that material as to which version of a purported
  17. standard format the material might be in, and even, in some cases,
  18. which profile of that standard might apply.
  19.  
  20. >> If I wish to retrieve the document, say to view it, I might want to
  21. >> choose the available representation that is most appropriate for my
  22. >> purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
  23. >> from an anonymous FTP archive, only to discover that it is in the
  24. >> newly announced Postscript level 4 format, or to try to edit it only
  25. >> to discover that it is in the (upwardly compatible but not parsable by
  26. >> my client) version 44 of Rich Text. In each case, the appropriateness
  27. >> of alternate sources and representations of a document would depend on
  28. >> information that is currently only available in-band.
  29.  
  30. >Even if this happens (I have strong doubts that it will since documents made
  31. >available for public retrieval tend to converge rapidly to lowest-common
  32. >denominator usage) you have failed to propose an alternative that solves this
  33. >usefully.
  34.  
  35. Documents made available for public retrieval do not cannot 'tend to
  36. converge rapidly to lowest-common denominator usage', because *old
  37. documents do not go away*! If there is diversity today in the
  38. available formats for RFCs, tech reports and PhD theses, that
  39. diversity can only get worse! It is foolish to think that the
  40. diversity will diminish any time in the near future; certainly the
  41. number of 'conference proceedings on CD-rom' is increasing, as people
  42. want to share Mathematica documents, various forms of hypertext, audio
  43. content and the like.
  44.  
  45. As for a proposal that 'solves this usefully', I have a fairly mild
  46. proposal that, while it does not solve all of the problems in
  47. interoperability, does reduce the amount of uncertainty:
  48.  
  49. I propose (once again) that instead of saying 'application/postscript'
  50. it say, at a minimum, 'application/postscript 1985' vs
  51. 'application/postscript 1994' or whatever you would like to designate
  52. as a way to uniquely identify which edition of the Postscript
  53. reference manual you are talking about; instead of being identified as
  54. 'image/tiff' the files be identified as 'image/tiff 5.0 Class F' vs
  55. 'image/tiff 7.0 class QXB'.
  56.  
  57. > Finally, let me point out that I speak as one of the maintainers of one of the
  58. > largest archive of TeX material available anywhere. This material has been
  59. > available via MIME-compliant mail server (and of course FTP) for over six
  60. > months now. This archive contains hundreds of PostScript documents as well
  61. > as all sorts of other stuff. The problems you seem to think are endemic to
  62. > this sort of services have yet to materialize.
  63.  
  64. I think you need to take a longer-term and broader perspective than a
  65. six-month experience with a single representation of document.
  66.  
  67.  
  68. We've been developing a document archive service that can cope with 20
  69. years of collected electronic documents. We have not only Postscript 1
  70. and 2, but also several versions of Interpress, and Press format, two
  71. versions of DVI, revisable formats of 20 years of editor development
  72. -- several versions of tex, latex, framemaker, microsoft word, tioga,
  73. globalview, viewpoint, bravo, bravox, tedit, troff, interleaf,
  74. wordperfect, etc, and images in multiple variations of RES, AIS, TIFF,
  75. sun raster, pcx, macpaint, ad nauseum.
  76.  
  77. In trying to deal with a documents over the longer term, it has become
  78. apparent that merely marking documents with a simple 'format' tag like
  79. 'interpress' or 'postscript' or 'tiff' isn't adequate for most
  80. purposes. Standards evolve over as short as a 5 year period; even the
  81. method of internal tagging standard versions changes, and certainly,
  82. it is impossible to rely on in-band version information for all
  83. formats. 
  84.  
  85. I have more to say about the problem of 'external references' but I'll
  86. save that for another message.
  87.  
  88. It would be nice to have a calm discussion about possible solutions to
  89. these problems & hope you will forgo future sarcasm.
  90.  
  91. Thanks,
  92.  
  93. Larry
  94.  
  95.